package tls;

public class TLS {
    /**
     * TLS里使用的混合加密方式,即把对称加密和非对称加密结合起来,两者互相取长补短,即能高效地加密解密,又能安全地密钥交换。
     * 1.通信开始的时候使用非对称算法如RSA,ECDHE先解决密钥交换的问题
     * 2.用随机数产生对称算法使用的“会话密钥”,在用公钥加密。会话密钥很短,所以即使使用非对称加密算法也可以很快完成加解密
     * 3.对方拿到密文后用私钥解密,取出会话密钥。完成对称密钥的安全交换。
     * 数字证书：
     * 数字证书组成：CA信息,公钥用户信息,公钥,权威机构的签名,有校期间数字证书作用：
     * 1.通过数字证书向浏览器证明身份
     * 2.数字证书里面包含了公钥
     */

    /**
     * TCP面向连接的
     * 可靠的
     * 基于字节流
     * 传输层协议
     */

    /**
     * 特点
     * 基于连接的：数据传输之前需要建立连接
     * 全双工的: 双向传输
     * 字节流：不限制数据大小,打包成报文段,保证有序接收,重复报文自动丢弃
     * 可靠的传输服务：保证可达,丢包时通过重传实现可靠性
     * 拥塞控制：防止网络出现恶性拥塞
     */

    /**
     * TCP连接管理：
     * 1.TCP连接：四元组[源地址,源端口,目的地址,目的端口]
     * 2.确立连接：TCP三次握手
     *
     * 三次握手
     * 1.客户端发送带有SYN标志为1,起始序seq号为随机数x的数据包到服务端,客户端进入SYN-SENT状态
     * 2.服务端发送带有SYN/ACK标志的数据包,其确认字段值到客户端;服务端进入SYN-RECEIVED状态;客户端接收服务端的
     * ACK包,进入ESTABLISHED状态
     * 3.客户端发送带有ACK标志的数据包给服务端,其中ack=y+1;服务端进入ESTABLISHED状态;客户端进入ESTABLISHED状态
     * 4.当客户端SYN报文到达时,将SYN包入队到操作系统内核的SYN队列中,服务端为SYN-RECEIVED状态；
     * 5.收到客户端的ACK包后,操作系统内核将SYN中的SYN包出队,再入队到ACCEPT队列,进入ESTABLISHED状态
     * 因此,JavaSocket通信编程中,调用ServerSocket.accept()时,连接处于第三次握手完成状态。
     */

    /**
     * 为什么需要三次握手？
     * 为了建立可靠的通信信道,数据的通讯就是数据的发送和接收,而三次握手的主要目的就是双方确认自己和对方的发送和接收是正常的
     * 第一次握手：客户端发送正常,服务端确认了对方发送正常,自己接收正常。
     * 第二次握手：客户端确认了：自己发送,接收正常,对方发送,接收正常。
     * 第三次握手：客户端确认：自己发送,接收正常,对方发送,接收正常;服务端确认：自己发送,接收正常,对方发送,接收正常。
     * 三次握手就能确认双方收发功能都正常,缺一不可。
     */

    /**
     * 为什么要传回SYN
     * 接收端传回发送端所接受的SYN为了告诉发送端,我接受的信息确实就是你发送的信号。
     * 传了SYN,为啥还要传ACK
     * 双方通信无误必须是两者相互发送信息都无误。传了SYN,证明发送方到接收方的通道没有问题。
     * 但是接收方到发送方的通道还需要ACK信号来验证。
     */

    /**
     * 四次挥手
     * 1.客户端发送一个FIN,用来关闭客户端到服务器端的数据传送;
     * 2.服务器收到FIN,它发回一个ACK,确认序号为收到的序号+1;和SYN一样,一个FIN将占用一个序号;
     * 3.服务器关闭与客户端的连接,发送一个FIN给客户端;
     * 4.客户端受到FIN,发送一个ACK包给服务端,并将序号设为收到序号+1;客户端关闭与服务端的连接。
     *
     */

    /**
     * 为什么要四次挥手
     * 任何一方都可以在数据传送结束后发出连接释放的通知,待对方确认后进入半关闭状态
     * 当另一方也没有数据再传送时,则发出连接释放通知,对方确认后,就完全关闭了TCP连接。
     *
     * 为什么等待2MSL后释放连接
     * 1.防止报文丢失,导致B重复发送FIN;
     * 如果A的响应报文丢失,B端会再次发送,如果不等待就关闭,那么B端连接无法关闭;
     *
     * 2.防止滞留在网络中的报文,对新建立的连接造成数据扰乱;
     * 如果A收到FIN包后就关闭,B端在发送FIN包附近时间点可能也发送其他的数据包,这些数据包延迟了,且A关闭,就会造成B的数据
     * 包滞留在网络中。
     *
     * 字节流的协议
     * TCP把应用交付的数据仅仅看成时一连串的无结构的字节流,TCP并不知道字节流的含义,TCP并不关心应用程序一次多大的报文发送到TCP的缓存
     * 中,而是根据对方给出的窗口值和当前网络拥堵的程度来决定一个报文段应该包含多少字节。
     *
     * TCP 面向连接 传输可靠 字节流传输形式 传输效率慢  所需资源多  应用场景(文件传输,邮件传输) 首部字节20-60
     * UDP 无连接 不可靠 数据报文段传输形式 传输效率高  所需资源少 应用场景(视频直播,音视频传输) 首部字节8
     * UDP 面向无连接的服务。传送数据之前不需要建立连接,远方主机收到UDP报文后,不需要给出确认,支持一对一,一对多,多对多的发送
     * TCP面向连接的无服。传输数据之前必须先建立连接,数据传输完后,释放连接,只支持一对一的发送
     *
     * 数据可靠性传输
     * 停止等待协议
     * 发送后,等到对方响应ACK报文；
     * 重传机制
     * 如果在一定时间内,没有接受到ACK报文,则认为数据包丢失了
     * 滑动窗口协议与累计确认(延时ack)
     * 滑动窗口大小通过tcp三次握手和对端协商,且受网络状况影响
     */
}
